Today I'd like to talk about test automation, which, OK, is not strictly speaking AI (although it does sometimes leverage the limited AI systems built into NPCs, enemies and bots to simulate gameplay) - but I thought of the funny title, so I'm sticking with it.
I actually don’t have much to add to this one from the neurospicy side, so I’ll embrace the ADHD part of my brain and instead talk about something totally off topic for a moment: paragraphs.
Wait, what? Yes you read that correctly. Paragraphs.
You may notice that I break my articles up into quite a few paragraphs, sometimes one (long) sentence at a time. Well that’s intentional - for me at least, I find looking at a page that’s not broken up like that genuinely painful (there’s like an ache just behind my eyes) and I find it very difficult to process any of the information on it. It's like a big wall of text and my brain just goes "nope...".
I actually don’t know why that is, although I suspect it’s something to do with attention span, or maybe being over-stimulated (too much writing, not enough blank, calm spacing), but either way this is just a little tip for anyone writing documentation, emails or other long messages to my fellow AuDHDers.
While we love getting lots of information (I’d personally rather just have access to everything and I’ll filter out what I don’t need myself, than you just give me the bare bones for fear of overloading me), it’s so much easier to process it when it’s formatted with some spaces!
Right then. 500 words .. begin!
There are a lot of concerns about test automation taking away QA jobs (although, obviously not test engineers, SDETs etc. who would all be involved in writing and maintaining it). I understand the fear, of course I do, but I have seen some odd comments float about that I wanted to address.
Chiefly, I saw one person raise concerns that “test automation taking over the boring, repetitive and mundane tasks means there's no work for juniors and interns”. While I appreciate there's always a balance to strike, and you don't want people running before they can walk, I was shocked at the implications here.
One of the main principles of team motivation and engagement is “give people a challenge” - just as we develop games with difficulty curves and periods of challenge mixed with a sense of power (creating a “flow zone”), we should be structuring our team's development to do the same. If juniors are only ever given the boring busy work, they will:
Rather than see automation as the end of games quality as we know it, we need to look at it as the beginning of what games quality could be, and probably should always have been: the assurance of quality.
Now I'm obviously not undervaluing the work that QA have done over the last few decades (that would be self-defeating if nothing else). Ensuring core functionality and verifying that implementation meets design is, of course, crucial, but if my only mark on a project is that “it works”, I don't feel like I've contributed to actual quality. My goal is always to help ensure that a game is good, that it's fun/challenging and that it meets player needs.
“That's user experience design”, I hear you say? Well thank you, disembodied voice of the reader, you're quite right. Which brings us nicely to my current hyper-focus: better integration between UX and QA.
And to be clear, QA should be integrated closely with all disciplines (we’ll talk “shift left” soon), but UX in particular is a sorely misunderstood discipline in games (generally speaking) and one which I think sits in a little Triforce of awesomeness with QA and Accessibility.
So rather than seeing automation as the end of QA, we need to see it as the end of QA doing the boring bits that even QA don’t really want to do! It has the potential to free us up to bring so much more value to projects, and ultimately to gamers, and to support teams even more efficiently than ever before.
So I’m actually excited about seeing more automation, and even AI, come into gaming. We just need to be ready!
And that’s that - 500!